A data processor is a well known device that forms the heart of almost any computer. A data processor operates on input data to create output data by executing a pre-specified algorithm. Typically, a processor functionally contains one or more of the following operation units: an arithmetic unit (e.g., ALU) to perform additions, subtractions, shifting, a multiplier (MUL) to multiply two data items, a random-access memory (RAM) to read and to write data, a read-only-memory (ROM) to only read data, an address calculation unit to provide addresses for access of the memories, or an application-specific unit (ASU). An ASU is a dedicated unit, typically used to execute operations that do not fit in with the instruction set of another operation unit within the restricted number of instruction cycles specified for that other operation unit. Mapping the surplus operations onto an ASU then may be more efficient than increasing the number of instruction cycles for the other operation unit or providing an additional operation unit of the same kind as the other operation unit.
A processor as introduced in the preamble above is disclosed in "PIRAMID: An Architecture-Driven Silicon Compiler for Complex DSP Applications", by R. Woudsma, F. P. M. Beenker, J. L. Van Meerbergen and C. Niessen, 1990 IEEE International Symposium on Circuits and Systems, New Orleans, La., U.S.A., May 1-3, 1990, pp. 2596-2600. FIGS. 2 and 3 of this prior art document show a modular architecture for a processor. The architecture is automatically generated by a silicon compiler (PIRAMID) on the basis of a functional specification for the processor. Unlike a conventional data processor that is frozen in silicon and that therefore must be configured to be general purpose, the processor generated by PIRAMID is optimized to the application envisaged.
The prior art document's FIG. 2 illustrates the processor's modular architecture having a plurality of execution units interconnected by data buses and controlled via a microcode program stored in a controller. The general structure of an execution unit is shown in the document's FIG. 3. An execution unit is a functional and physical entity that performs one or more operations required to implement the algorithm. Each execution unit therefore comprises an operation unit, of the kind discussed above to actually perform the operation, and a register file to store the input data used as operands by the operation unit and to supply the input data to the operation unit when needed.
Generally, the register file comprises an "A"-register file section and a "B"-register file section. The "A"-register file section supplies the "A"-operand and the "B"-register file section supplies the "B"-operand to the operation unit. The operation unit thereupon operates on both operands. For instance, the operation unit may interpret both "A"- and "B"-operands as data to be subjected to a logic or mathematical operation. If the operation unit includes a RAM, it receives the "A "-operand as data to be stored at an address specified by the "B"-operand. Operations involving both "A"- and "B"-operands are called "dyadic" operations, whereas an operation involving only a single operand is called a "monadic" operation. As an example of the latter, an operation unit that includes a ROM only needs a single operand, namely a ROM's address. The ROM register file therefore only comprises an "A"-register file section.
A register file is a dual-ported device that is operative to execute a read operation and a write operation in a single instruction cycle. The register file serves as a fast foreground memory connected to the operation unit. A background memory is a single-ported device and can perform only one read operation or one write operation in a single instruction cycle. The background memory therefore is slow as compared to the foreground memory and is treated as an operation unit of a separate execution unit (e.g., RAM, ROM). Register files are addressed by the controller via an instruction register, whereas the background memory is addressed via address calculation units implemented in another execution unit. Note that each individual execution unit has its own register file.